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Abstract 

The popularity of Tor as an anonymity system has made 
it a popular target for a variety of attacks including block¬ 
ing, denial of service, and timing attacks. In this paper, we 
focus on timing attacks which are no longer solely in the 
realm of academic research with recent revelations about 
the NS A and GCHQ actively working to implement them in 
practice. We specifically focus on recently exposed timing 
attacks that leverage asymmetric routing and information 
gained on reverse network paths (e.g., via TCP ACK num¬ 
bers) to deanonymize Tor users. 

First, we present an empirical study which leverages scal¬ 
able algorithmic simulations of routing policies on an up-to- 
date map of the Internet’s topology, including complex AS 
relationships and sibling ASes. Our approach allows us to 
gain a high fidelity snapshot of the threat of timing corre¬ 
lation attacks in the wild. In our experiments we find that 
58% of all circuits created by Tor are vulnerable to attacks 
by timing correlation and colluding sibling ASes. In addi¬ 
tion, we find that in some regions (notably, China) there 
exist a number of cases where it is not possible for Tor to 
construct a circuit that is safe from these correlation attacks. 

To mitigate the threat of such attacks, we build Astoria- 
an AS-aware Tor client. Astoria uses leverages recent 
developments in network measurement to perform path- 
prediction and intelligent relay selection. Astoria not only 
reduces the number of vulnerable circuits to 5.8%, but also 
considers how circuits should be created when there are 
no safe possibilities. Astoria also performs load balancing 
across the Tor network, so as to not overload low capacity 
relays. In addition, Astoria provides reasonable performance 
even in its most secure configuration. 


1. INTRODUCTION 

Tor is a popular anonymity system for users who wish 
to access the Internet anonymously or circumvent censor¬ 
ship 1 . The increasing popularity of Tor has recently made 
it a large target for blocking and denial of service 2 -[2] and 
timing attacks to deanonymize users [5]|9j. Timing attacks, 
which correlate traffic entering the Tor network with traf¬ 
fic exiting it, are no longer solely in the realm of academic 
research with recent revelations about the NS A and GCHQ 
actively working to implement them in practice, in collusion 
with Internet Service Providers 10 - 
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Timing attacks have been shown to be feasible and practi¬ 
cal for network-level attackers. Specifically, a timing attack 
may be implemented by any autonomous system (AS) that 
lies on both, the path from the Tor client to the entry relay 


and the path from the exit relay to the destination. Previ¬ 
ous studies have demonstrated the potential for this type of 
attack HP, 14 and have proposed relay selection strategies 
to avoid common ASes (potential attac kers ) that may per¬ 
form them 15]. However, recent work 16 has shown that 
these strategies perform poorly in practice. 

The threat of network-level adversaries has been exacer¬ 
bated by a recent study which highlights that the set of po¬ 
tential ASes that may perform timing analysis is potentially 
much larger due to asymmetric routing, routing instabili¬ 
ties, and intentional manipulations of the Internet’s routing 
system 117 ,[l8]. These attacks significantly raise the bar for 
relay-selection systems. Specifically, they require the relay- 
selection system be able to accurately measure or predict 
network paths in both the forward and reverse direction. 
Measuring the reverse path between two Internet hosts is 
non-trivial, especially when the client does not have control 
over the destination, as is commonly the case for popular 
Web services. While solutions for measuring reverse paths 
have been proposed [19], they are still not widely deployed 
or available. 

In this paper, we quantify the threat posed by these new 
attacks, and develop a relay selection method to minimize 
their impact. We leverage up-to-date maps of the Internet’s 
topology 20] combined with algorithmic simulations 21 to 
predict which ASes are in a position to perform timing anal¬ 
ysis on forward or reverse paths. We then augment our 
analysis with techniques to identify ASes owned by a single 
organization (sibling ASes) in order to gain a clearer pic¬ 
ture of which ASes are likely to collude with each other. 
This provides a more accurate impression of network-level 
threats than previous work. Through these techniques, we 
make the following key observations: 

• 58% of circuits constructed by Tor are vulnerable to 
network-level attackers. 

• 43% of all sites in the local Alexa Top 500 of Brazil, 
China, Germany, Spain, France, England, Iran, Italy, 
Russia, and the United States had main content that 
was not reached via a safe path - i.e., a path that was 
free from network-level attackers. 

• Connections from China were found to be most vulnera¬ 
ble to network-level attackers with 85.7% of all Tor cir¬ 
cuits and 78% of all main content requests to sites in 
the local Alexa Top 500 being vulnerable to colluding 
network-level attackers. 

• Reducing the number of entry guards results in an in¬ 
crease in vulnerability of Tor circuits in several countries. 
The most drastic loss of security was seen in Spain. In 







particular, Tor with 3 guards (default) had 34.8% vul¬ 
nerable circuits, Tor with 2 guards had 59.8% vulnerable 
circuits, and Tor with a single guard had 75.7% vulner¬ 
able circuits. 

We propose, construct, and evaluate Astoria-an AS-aware 
Tor client that includes both, security and relay bandwidth 
considerations when creating Tor circuits. Astoria is the 
first AS-aware Tor client to consider the recently proposed 
asymmetric correlation attacks M- When there are safe 
alternatives, Astoria actively avoids using circuits on which 
asymmetric correlation attacks might be launched. It also 
leverages, methods to identify sibling ASes [22] when deter¬ 
mining whether or not a given circuit is safe. In the absence 
of a safe path, Astoria uses a linear program to minimize the 
amount of threat posed by any adversary. Finally, Astoria 
considers the bandwidth capabilities of relays while making 
AS-aware relay selection decisions. Astoria aims to be a 
good network citizen and allows users to adjust how their 
circuits distribute load across Tor relays. Even in it’s most 
secure configuration, Astoria will not overload slow relays. 


Paper outline. In Section [2] we briefly overview how 
the current Tor client performs relay selection and circuit 
construction, describe the current state of research in relay 
selection for Tor, and introduce our adversary model. In 
Section [3] we describe the components of our measurement 
toolkit used for detecting network-level attackers on Tor cir¬ 
cuits. We then present some interesting results regarding the 
prevalence of attackers on Tor constructed circuits and the 
general potential for attack by adversaries described in our 
model. In Section [4] we present the details of our AS-aware 
client - Astoria. A performance and security evaluation of 
Astoria is performed in Section [5] In Section [6] we discuss 
methods for improving Astoria performance and discuss its 
usability. We make our conclusions in Section [7] 


2. BACKGROUND AND MOTIVATION 

We now provide background on Tor relay selection, related 
work in this area, and introduce our adversary model. 

2.1 Tor relay selection 

The Tor anonymity network consists of approximately 
6,000 relays (Tor routers). Most requests made through a 
Tor client are sent to their destination via a three-hop path 
known as a circuit. Each circuit consists of an entry, middle, 
and exit relay. The entry-relay communicates directly with 
the client making the request, and the exit-relay communi¬ 
cates with the destination of the request. The fundamental 
idea is that no single relay in the circuit learns the source 
and the destination of the request. 

In its early days, Tor selected relays for each section of 
a circuit uniformly at random from the set of available cir¬ 
cuits. This was changed in order to improve performance 
(by preferring to route through higher bandwidth relays [23] ) 
and security [24]. In today’s Tor network, based on certain 
performance characteristics such as reliability, bandwidth 
served, and up-time, relays may earn certain flags that make 
them a preferential choice for various roles during circuit 
construction. 

One such flag is the guard flag. New relays joining the 
Tor network are monitored for stability and performance 
via remote measurements for a period of up to eight days 
[25] . At this point, relays that have shown to be stable 
and reliable are assigned a guard flag. Relays with a guard 


flag earn the ability to serve as the entry-relay to the Tor 
network. By default the Tor client selects three guards to be 
used as entry-relays for all circuits for a prolonged period of 
time. The main ideas behind the selection of a fixed set of 
entry-relays are (1) to reduce the possibility that a client will 
select an entry- and exit-relay operated by the same entity 
after prolonged use, (2) prevent attacker owned entry-relays 
from denying service to clients that are not also using an 
exit-relay owned by the attacker, and (3) increase the cost 
to an attacker that wishes to be chosen as an entry-relay, by 
requiring them to earn the guard flag [25] . 

In addition to picking routers that are more stable and 
reliable, for other locations on a circuit, the Tor client also 
requires that (1) no two routers on a circuit share the same 
/16 subnet and (2) no routers in the same family (as adver¬ 
tised by the router) may be chosen on the same circuit. [23] . 

2.2 Related work 

The threat of correlation attacks by AS-level adversaries 
on the Tor network was first identified and empirically eval¬ 
uated by Feamster and Dingledine 14] in 2004, when the 
Tor network had only 33 relays and significantly different 
relay selection algorithms. The study revealed that 10-30% 
of all circuits constructed by Tor had a common AS that 
could observe both ends of the circuit. Shortly after, by con¬ 
structing efficient traffic correlation attacks while consider¬ 
ing network-level adversaries, Murdoch and Danezis [5] and 
Murdoch and Zielinski 7] demonstrated that the threat from 
AS-level attackers was one of practical concern. In 2009, 
Edman and Syverson [l3] found that the threat of AS-level 
adversaries had not reduced since [l4], in spite of revised 
relay selection strategies and substantially larger number of 
relays in the network. 

Johnson et al. 9 performed an empirical evaluation of 
the effect of adversary bandwidth investment strategies, Tor 
client location, and Tor client use ( e.g., for IRC, brows¬ 
ing, Bit Torrent, etc.). They found that a network adver¬ 
sary could effectively de-anonymize most Tor users within 
six months with very low bandwidth costs. 

Most recently, Vanbever et al. 17] and Sun et al. 18], 
presented RAPTOR, an AS-level attack integrating BGP 
interception with a simple correlation attack that takes ad¬ 
vantage of the asymmetric nature of Internet routing, to 
exactly de-anonymize Tor users with up to 90% accuracy in 
just 300 seconds. RAPTOR emphasizes the need for Tor 
relay selection strategies to consider ASes that lie both, on 
the forward and reverse paths between the (client, entry) 
and (exit, destination). 

Perhaps most closely related to our work, Akhoondi et 
al. 15], constructed LASTor, a Tor client which explicitly 
considered AS-level attackers and relay locations while con¬ 
structing Tor circuits. While LASTor appeared to success¬ 
fully reduce path latencies and the probability of common 
ASes at either end of the Tor circuits, it neglected the ca¬ 
pacity of relays selected by the system. Relay capacity is 
an important variable to consider to ensure that custom re¬ 
lay selection schemes do not overload a small set of relays 
- therefore reducing the performance of the entire network. 
Their evaluation, based on only HTTP HEAD requests (as 
opposed to webpage loads), did not stress the system suffi¬ 
ciently to reveal the issues associated with capacity-agnostic 
relay selection. Further, LASTor does not consider an ad¬ 
versary that may (1) collude with other ASes, and/or (2) 






Forward path — ^ Reverse path 

Figure 1: Standard and reverse-path timing attacks. In the stan¬ 
dard timing attack, AS2 must observe the direction of the connec¬ 
tion that data is flowing on (forward path). In the reverse-path 
timing attack AS2 can infer the data flow using ACK numbers on 
the reverse path. 

only need to be on one of the asymmetric path segments be¬ 
tween source and entry-relay; and exit-relay and destination 
(e.g., RAPTOR). 

2.3 Adversary model 

In the standard view of timing attacks, an AS needs to 
lie on the forward patlQ between the source and destination 
(i.e., on the solid green colored path segments in Figure [l] 
(a)). With this view point the adversary (AS 2) can view the 
packet sizes as transmitted from the source to destination, 
going-into and coming-out-of the Tor network and directly 
perform a timing attack. 

However, recent work by Vanbever et al. 17 and Sun et al. 
p~8] highlights the fact that an adversary on the reverse path 
may also learn packet size and timing information via the 
TCP Acknowledgement (ACK) held. Figure [ljb) illustrates 
this case. AS 2 can directly observe packet timings between 
the source and entry-relay AS (Entry AS), but can only 
observe ACKs from the destination back to the exit-relay 
AS (Exit AS). 

In this view, an adversary has the potential to launch a 
timing attack on a Tor circuit as long as the following criteria 
are satisfied: 

Let Psrc^entry = {ASi , AS 2 , • • •, AS n } be the set of 
ASes on the path from the source (Tor client) to the se¬ 
lected entry-relay (this set includes the entry-relay AS), 
Pentry^src — {AS [, AS' 2 ,..., AS ^} be the set of ASes on 
the path from the entry-relay back to the source, and 

Pentry-^src — Pentry^-src ^ Psrc—Gentry • 

We similarly define paths to and from the exit-relay and 
destination (e.g., a popular content provider, or other Web 
Service) as Pexit^rdsti Pdst^&xiti and Pexit-^dst- 

We say that a Tor circuit is subject to attack if there exists 
an AS Ai such that: 

Ai £ {psre-entry C Pexit^dst } 

Similar to prior work on relay selection, we assume that 
our adversary is an autonomous system (AS), or an entity 
working with the cooperation of ASes (e.g., governments). 
However, while ah previous work only considers the standard 
view of network attacks, we also consider attackers that may 
he on the reverse-path, as described above. In addition, we 
also include the possibility that some sets of ASes may col¬ 
lude with each other to de-anonymize Tor users. Specifically, 

1 Here we use ‘forward path’ to refer to the direction of data 
flow in the TCP connection 


we consider that an AS may collude with sibling ASes [22] - 
i.e., other ASes owned by the same organization. Finally, we 
consider that our adversary may run surveillance activities 
over a long period of time. As part of our relay selection 
algorithms (Section [4|, we consider a probabilistic relay se¬ 
lection strategy that minimizes the amount of traffic that is 
observable by any single attacker. 

3. MEASURING ADVERSARY PRESENCE 

In this section, we investigate the prevalence of the ad¬ 
versary we describe above. We detail how prediction of AS 
paths between a source and a destination is performed and 
how sets of potential attacking ASes are generated. Then, 
we provide a description of our measurement setup and our 
findings. 

3.1 Predicting attacking ASes 

Adversaries that can exploit asymmetric routing present 
a challenge to measuring their prevalence. While forward 
paths are simple to measure (via forward traceroutes), the 
addition of potential attackers on the reverse-path between 
a source and destination implies the need for identifying 
potential attackers on the reverse-paths between the client 
and entry-relay (and the exit-relay and destination) path. 
This poses a serious problem, since obtaining information 
about reverse-paths is far less straightforward. While Re¬ 
verse Traceroute [l9 would be a useful tool for these mea¬ 
surements, it is not widely deployed. 

Additionally, since our measurement toolkit was assem¬ 
bled with the goal of integration with our Tor client - Astoria 
(Section [4|, using external measurement and control-plane 
mapping tools (e.g., iPlane [26]) was not an option. This is 
because such tools require knowledge of the clients intended 
destination - an undesirable option for an anonymity tool 
such as Tor. Thus, any measurement or path prediction 
needs to be performed on the Tor client without leaking 
any information to attackers or third party tools and service 
providers. 

To address the aforementioned challenges we employ an ef¬ 
ficient path prediction approach which leverages up-to-date 
maps of the AS-level Internet topology [20 , and algorith¬ 
mic simulations that take into account a common model of 
routing policies [21 . 

AS-level topology. We perform path prediction using an 
empirically-derived AS-level Internet topology. In this ab¬ 
straction, the Internet is represented as a graph with ASes as 
nodes and connections between them represented as edges. 
Connections between ASes are negotiated as business ar¬ 
rangements and are often modeled as two main types of re¬ 
lationship: customer-provider where the customer pays the 
provider for data sent and received; and settlement-free peer¬ 
ing or peer-peer where two ASes agree to transit traffic at 
no cost 27 . 

However, in practice AS relationships may violate this 
simple taxonomy e.g., ASes that agree to provide transit for 
a subset of prefixes (partial transit ) or ASes that have dif¬ 
ferent economic arrangements in different geographic regions 
(hybrid relationships ) [20]. It can also be the case that two 
ASes are controlled by the same organization e.g., because 
of corporate mergers such as Level 3 (AS3356) and Global 
Crossing (AS3549) or organizations that leverage different 
AS numbers in different regions such as Verizon (AS701, 
702, 703). The AS-level topology we leverage takes partial 



Entry ASes Exit ASes 



Figure 2: Illustration of the AS paths that the client needs to 
predict, note that these paths must be predicted for each potential 
entry and exit relay in both the forward and reverse direction. 

transit and hybrid relationships into account, and we use 
techniques discussed by Anwar et al [22] for detecting sib¬ 
ling ASes. This is done to identify ASes that are likely to 
collude with each other. 

Routing policies. Routing on the AS-graph deviates 
from simple shortest path routing because ASes route their 
traffic based economic considerations. We use a standard 
model of routing policies proposed by Gao and Rexford [27]. 
The path selection process can be broken down into the fol¬ 
lowing ordered steps: 

• Local Preference (LP). Paths are ranked based on their 
next hop: customer is chosen over peer which is chosen 
over provider. 

• Shortest Paths (SP). Among the paths with the highest 
local preference, prefer the shortest ones. 

• Tie Break (TB). If there are multiple such paths, node a 
breaks ties: if b is the next hop on thepath, choose the 
path where hash, if (a, b) is the lowestr] 

This standard model of local preference [27] captures the 
idea that an AS has incentives to prefer routing through a 
customer (that pays it) over a peer (no money is exchanged) 
over a provider (that it must pay). 

In addition to selecting paths, ASes must determine which 
paths they will announce to other ASes based on export 
policies. The standard model of export policies captures the 
idea that an AS will only load its network with transit traffic 
if its customer pays it to do so [27] : 

• Export Policy (EP). AS b announces a path via AS c to 
AS a iff at least one of a and c are its customers. 

Computing paths following these policies using simulation 
platforms (e.g., CBGP 28]) can be computationally expen¬ 
sive which limits the scale of analysis. Thus, we employ 
an algorithmic approach [2l] that allows us to compute all 
paths to a given destination in (9(|V| + \E\) where \V\ is 
the number of ASes and \E\ is the number of edges. Fol¬ 
lowing [|T], we call this computation of all paths to a given 
destination “computing the routing tree” for the destination. 
Predicting paths. We use the routing policies and al¬ 
gorithmic simulations 121 as described above to compute 
routes between pairs of ASes using the AS-level topology 
published by CAIDA [20]. While it is difficult to predict 
the specific AS-level path between a source and destination 
AS, recent work shows that 65-85% of measured paths are in 
the set of paths which satisfy LP and SP above [22]. Thus, 
we modify the algorithmic simulator to return all paths sat¬ 
isfying LP and SP simultaneously, instead of using TB to 

2 In practice, this is done using the distance between routers 
and router IDs. Since we do not incorporate this information 
in our model we use a randomized tie break which prevents 
certain ASes from “always winning”. 


produce a unique path. We consider the set of ASes in the 
set of paths satisfying LP and SP between a and b to be the 

Set Pa^f-i). 

For standard measurement purposes, the toolkit simply 
takes a source and destination address and returns the set 
of ASes on the forward and reverse-path between the two. 

However, in the context of integration with our Tor client, 
it must predict paths to and from each of the entry-relays 
for the client’s AS, and paths from all exit-relays toward the 
destination AS (Figure [5|. This results in \En\ + \Ex\ + 2 
routing-tree computations where \En\ and \Ex\ are the num¬ 
ber of entry and exit relays, respectively. In order to miti¬ 
gate the risk of correlation attacks, by default, Tor restricts 
the number of entry-relays available to each Tor client to 
three (called guards [29]), and there are typically of the or¬ 
der of 1,000 exit-relays available to a client during circuit 
construction. The effect of reducing the number of entry- 
relays available to each client in the context of our adversary 
model is discussed in Section [3721 

Fortunately, since the source AS and entry-relay ASes 
are relatively stable, these paths can be precomputed for 
later use by the client. (We observe the benefit of this in 
Section [5]) However, performing relay selection on a per- 
destination basis means that pre-building circuits, as is done 
by the current implementation of Tor, is no longer feasible. 
In Section[4] we show how integrating our path measurement 
toolkit impacts the performance of our Tor client. 
Identifying attacked circuits. Once our path pre¬ 
diction toolkit returns the set of ASes that occupy each 
(forward and reverse-) path from the Tor client to a given 
entry-relay and from an available exit-relay to the destina¬ 
tion, potential circuits are labeled as under attack iff there 
are common or sibling ASes on the (client, entry-relay) and 
(exit-relay, destination) path. This is in line with our adver¬ 
sary model described in Section [2] 

3.2 Results 

To understand the threat posed by the adversary de¬ 
scribed in Section [2] we performed several experiments. In 
particular, our goal was to understand the threat faced by 
the Tor client under various configurations, and in different 
locations. 

Experimental setup. In our experiments, we consider 
the fact that Tor users in different countries face different 
levels of threats from local ASes. To this end, we performed 
page loads using several configurations of the Tor client from 
10 different countries: Brazil (BR), China (CN), Germany 
(DE), Spain (ES), France (FR), England (GB), Iran (IR), 
Italy (IT), Russia (RU), and the United States (US). This 
list was obtained by considering various intersections of the 
number of Tor users in each country [30] and the Freedom 
House rankings for Internet freedom |31] , 

A VPN service was used to perform page loads of the 
Alexa Top 500 local sites [32] from within each of the afore¬ 
mentioned countries. Page loads were performed using the 
Tor client in four configurations: vanilla (default: three en¬ 
try guard restricted Tor), one entry guard restricted Tor, 
two entry guard restricted Tor, and a modified Tor client 
performing entry- and exit-relay selection uniformly at ran¬ 
dom. 

For each configuration, logs were maintained to track: (1) 
the list of available entry- and exit-relays during circuit con¬ 
struction, (2) the actual chosen entry and exit-relay for each 




Siblings 

Vanilla 

Tor 

Tor 

(2Guards) 

Tor 

(IGuard) 

Uniform 

Tor 

Main 

Yes 

43 . 1 % 

35 . 9 % 

37 . 0 % 

36.8% 

Main 

No 

42.4% 

34 . 8 % 

36.2% 

34.2% 

All 

Yes 

59.0% 

52.4% 

54.4% 

65.0% 

All 

No 

58.6% 

51.7% 

53.7% 

62.9% 


Table 1: Percentage of circuits carrying main requests for the 
Alexa Top 500 websites (of 10 countries) that are under threat 
and percentage of all circuits under threat for various relay 
selection strategies. 



Countries 

Figure 3: The fraction of circuits used by Vanilla Tor in each 
country (for main and any requests) that are vulnerable to asym¬ 
metric colluding attackers. 


circuit constructed by the client, and (3) the list of requests 
made for each site and the circuit used by the Tor client to 
serve the request. 

In addition to the source AS (AS of the VPN) and the 
destination AS (AS of the web content), ASes of the entry- 
and exit-relays (available and used) were extracted from our 
logs and input to our measurement toolkit to identify the 
set of attackers actually present on the constructed Tor cir¬ 
cuit (“actual attackers”) and attackers that could have been 
present had a particular entry- and exit-relay combination 
been selected (“potential attackers”). 

Since VPN vantage points only represent a single AS in 
a given country, we augment our results with simulations 
of network paths from a random sample of 100 ASes in a 
selected subset of the countries. Using data regarding the 
available entry- and exit-relays for a client, we computed the 
number of potential attackers in each AS. 

The results of our VPN- and simulation-based experi¬ 
ments are presented below. 

Live Tor network results. A summary of the results 
of our experiments on the live Tor network is illustrated in 
Table [l] As can be seen, the threat from de-anonymization 
is alarmingly high. When using the default configuration of 
Tor, 43% of all circuits carrying the main request (GET) 
for each site and 59% of all circuits are under threat from 
colluding network-level attackers. 

Figure [3] breaks down these numbers by country, showing 
the fraction of circuits built for the main page and any re¬ 
quest for the top sites that are vulnerable to the attacker. 
We find that the threat of asymmetric colluding attackers 
is not uniformly spread. Clients using Tor from three coun¬ 
tries: China (CN), Russia (RU), and the United States (US) 
are found to be most vulnerable, while rather surprisingly, 
clients connecting from Brazil (BR), Spain (ES), and Iran 
(IR) are found to be the least vulnerable to our attacker. 

One must remember, however, that the techniques for 
finding sibling (colluding) ASes does not capture the no¬ 
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Figure 4: Distribution of of the fraction of colluding and asym¬ 
metric correlation attacker-free circuits for 100 source ASes con¬ 
necting to local Alexa Top 100 sites in 7 countries of interest. 


tion of governments and dictatorial regimes who may enforce 
traffic monitoring across networks managed by distinct or¬ 
ganizations. 

Simulation results. Since the results of our experi¬ 
ments on the live Tor network were highly dependent on 
the location of the VPN, simulations were required to un¬ 
derstand the distribution of threat in other locations within 
each country. To this end, seven countries were selected 
for further investigation: Brazil (BR), China (CN), Ger¬ 
many (DE), England (GB), Italy (IT), Russia (RU), and 
the United States (US). In each country, 100 ASes were ran¬ 
domly selected as client locations and the Alexa local Top 
100 sites were used as destinations. The simulation toolkit 
generated a list of entry- and exit-relays available to each 
client for performing the page load (using Tor client gener¬ 
ated data of currently available entry- and exit-relays on the 
network). 

Each generated entry- and exit-relay combination was 
then analyzed for the presence of attackers to understand 
how many “safe” or “attacker-free” paths were available. We 
see in Figure [4] the cumulative distribution function of the 
fraction of attacker free circuits. China (CN) stands out 
as the most interesting case. First, we see that there are 
~ 10% of all requests generated have no attacker-free cir¬ 
cuits! Next, we also notice that there are no known at¬ 
tackers present on « 20% of all requests. This appears to 
indicate that the threat of de-anonymization is non-uniform 
even within a country, with certain client locations being 
much safer than others. 

The effect of guards. Table [2] shows the effect of 
reducing the number of guards available to the Tor client 
during circuit construction. As can be seen, the benefit of 
reducing the number of guards for preventing correlation at¬ 
tacks is completely location dependent. In countries such as 
England (GB) and Iran (IR) the benefit is very pronounced 
with fewer guards drastically decreasing circuits that are 
vulnerable to our attacker. However, in other countries such 









































































as China (CN), Spain (ES), and Italy (IT) the situation is 
either marginally or much worse with the number of vul¬ 
nerable circuits actually increasing as the number of guards 
decreases. This is counter to the intuition that a smaller 
guard set will provide better security [29 . Our result is 
likely impacted by the concentration of guards in specific 
ASes, a problem identified in previous work 18]. It is clear, 
however, that there cannot be a universal rule regarding the 
optimal number of guards that a client must use, without 
knowing the location of the client. 


Country 

Siblings 

Three 

Guards 

Two 

Guards 

One 

Guard 

BR 

Yes 

43 . 6 % 

29.2% 

37 . 5 % 


No 

43 . 6 % 

28.2% 

32.3% 

CN 

Yes 

85.7% 

86.7% 

86.0% 


No 

85.4% 

86.5% 

85.9% 

DE 

Yes 

56.1% 

27.0% 

42.7% 


No 

54.7% 

27.0% 

40.7% 

ES 

Yes 

34.8% 

59.8% 

75.7% 


No 

34.8% 

58.9% 

75.5% 

FR 

Yes 

61.6% 

59.8% 

58.6% 


No 

61.6% 

59.8% 

58.5% 

GB 

Yes 

62.9% 

72.0% 

21.5% 


No 

61.8% 

67.9% 

21.5% 

IR 

Yes 

34.1% 

33.1% 

16.6% 


No 

34.0% 

33.1% 

16.5% 

IT 

Yes 

59.0% 

41.2% 

81.4% 


No 

59.0% 

40.3% 

79.1% 

RU 

Yes 

77.4% 

47.0% 

66.6% 


No 

76.6% 

47.0% 

66.5% 

US 

Yes 

73.1% 

67.8% 

59.5% 


No 

73.0% 

67.8% 

59.4% 


Table 2: Percentage of total circuits under threat when low¬ 
ering the number of guards. 

The effect of sibling ASes. From the results seen 
thus far, it appears that the increase in threat levels when 
considering sibling ASes is marginal in most cases. Table 
[3] shows the increase in the number of attacked requests at 
the corresponding fraction of attacker-free circuits, for each 
of the seven countries analyzed in our simulations, when 
siblings were considered as colluders. As expected, the im¬ 
pact is completely location dependent. We see that clients 
in China (CN) and the United States (US) face the most 
threat from colluding ASes, with over an additional 1% of 
web requests facing the scenario of having less than 10% 
of all available circuits be safe from the adversary, making 
it much more likely for these requests to be served via a 
vulnerable circuit, if using the vanilla Tor client. 


Country 

10 % 

25% 

50% 

75% 

BR 

0.7% 

3 . 2 % 

9 . 2 % 

5 . 9 % 

CN 

1.4% 

1 . 8 % 

3 . 1 % 

0 . 7 % 

DE 

0.1% 

0 . 3 % 

4 . 0 % 

6 . 1 % 

GB 

0.2% 

1 . 3 % 

6.6% 

6 . 2 % 

IT 

0.0% 

2 . 8 % 

5.5% 

5 . 5 % 

RU 

0.0% 

0 . 8 % 

4.4% 

4 . 4 % 

US 

1.0% 

2 . 5 % 

7.9% 

3 . 0 % 


Table 3: Percentage increase in the number of requests with 
fewer than 10, 25, 50, and 75% attacker-free circuits, when 
considering sibling ASes as colluders . 


4. Astoria: AN AS- AND CAPACITY- 
AWARE TOR CLIENT 

Motivated by the observation that vanilla Tor very often 
selects paths that may be subject to an adversary that ex¬ 
ploits asymmetric network paths, we seek to design a relay 
selection algorithm to mitigate the opportunities for such 
attackers. We design our relay selection system, Astoria, 
based on the idea of stochastic relay selection. This works 
by having the Tor client generate a probability distribution 
that minimizes the chance of attack over all possible relay se¬ 
lection choices, and selecting an entry- and exit-relay based 
on this distribution. The advantage of such a stochastic 
selection is that if the client has no safe options, choosing 
randomly can be engineered to minimize the amount of in¬ 
formation gained by a given adversary (as we show below). 
Further, it allows clients to skew their relay selection towards 
relays with higher capacity. 

4.1 Astoria Goals 

Astoria is constructed with several goals in mind: 

• Deal with asymmetric attackers. Astoria avoids con¬ 
structing circuits involving common ASes on the 
forward- or reverse-paths between the client to the entry- 
relay and the exit-relay and the destination. This mit¬ 
igates the threat from RAPTOR style [l8] asymmetric 
correlation attacks. 

• Deal with the possibility of colluding attackers. Astoria 
considers the evermore real threat of ASes that may col¬ 
lude to de-anonymize users of anonymity tools. Astoria 
can be configured to build circuits that do not contain 
known to be colluding ASes on the forward- or reverse- 
path between the client and entry-relay and exit-relay 
and destination. 

• Consider the worst case possibility. Astoria uses a prob¬ 
abilistic relay selection algorithm that ensures, even in 
the worst-case (where there are no safe paths to and from 
the entry- and exit-relay), that no single AS (or, family 
of ASes) is able to de-anonymize a large number of the 
client generated circuits. This is done by minimizing the 
number of circuits that route through each attacker AS. 

• Minimize performance impact. It is clear that any client 
which aims to be AS-aware and considers the above 
threats, will lose the ability to perform many optimiza¬ 
tions such as pre-constructing circuits. Our goal is to 
minimize the effect of the above considerations on the 
performance of the Tor client. 

4.2 Minimizing information gained by any 
adversary 

While there often are cases when there is a relay selection 
that will completely eliminate the risk of our adversary, we 
develop our relay selection to be robust, even if this is not 
the case. Further, with attacks implemented using BGP 
hijacking and interception the number of unsafe paths may 
be higher than what we observe in or analysis (we discuss 
this more in Section [6]). 

To limit the risk of timing attacks, we define a linear pro¬ 
gram which generates a probability for each relay selection 
with the objective to minimize the maximum probability of 
a circuit encountering any attacker. Recall in our adver¬ 
sary model that we consider a long-lived adversary and that 
minimizing the probability of an attacker may also be seen 
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Figure 5: Example of optimizing relay selection. Simplified to 
unidirectional paths and only entry-relay selection. 

as minimizing the number of circuits the adversary is able 
to observe over a long period of time and numerous circuit 
construction cycles. 

Figure [5] shows an example of relay selection to give in¬ 
tuition about how the LP minimizes the risk of a given at¬ 
tacker. In this example, we consider unidirectional paths 
and only entry-relay selection for clarity. In the figure, if 
the source were to choose uniformly at random across the 
three entry-relays, there is a 2/3 chance that AS 1 will be 
able to observe traffic and only a 1/3 chance that AS2 will. 
In this case, the optimal selection is intuitive, that the source 
should choose entry-relays 1 and 2 with probability 1/4 each 
and entry-relay 3 with probability 1/2. This lowers the prob¬ 
ability that AS 1 can observe a circuit from 2/3 to 1/2. This 
probability of the most likely adversary is the quantity that 
our LP minimizes. 

We use the following notation: 

• Let ADVi,j be the set of attackers on the circuit using 
entry-relay i and exit-relay j to destination dest - i.e., 
VA G ADViJ I A G ( Psrc^f-entryi ) H A G (Pexitj iciest )• 

• Let Xij : A be an indicator random variable for attacker 

A on the circuit using entry-relay i and exit-relay j - i.e., 
Xij t A = 1 A G ADVij, and 0 otherwise. 

• Let Pij be the probability that a circuit using entry-relay 
entryi and exit-relay exitj is utilized by the client. 

The following linear program is used to minimize the prob¬ 
ability of the most likely attacker (i.e., the number of circuits 
visible to any attacker). 

minimize z 

subject to z > Xu, a) VA 

h j 

Pu e [o, i] Vi, v? 

E = 1 

i, 3 

Essentially, given information about the presence of at¬ 
tackers for each p SO urce^i and Pj^dest path, the linear pro¬ 
gram seeks to find the probability distribution (Pi,j) over 
available choices of entry- and exit-relays, for which the ex¬ 
pected number of circuits visible to each attacker is mini¬ 
mized. Entry- and exit- relays are chosen according to this 
distribution during circuit construction. 

4.3 Security is not enough 

While our LP produces a relay selection distribution that 
minimizes the probability of each adversary, it does not take 
into account the resources available at the selected relays. 


> 



(a) Entry relay distribution. 

> 



(b) Exit relay distribution. 

Astoria linear program selected relays — 
Available tor relays 

Figure 6: Distribution of Astoria linear program selected entry 
and exit relay bandwidths, compared to available relay band- 
widths. 


Given that Tor is a system run using community resources 
contributed by volunteers, load balancing users across these 
resources is important to ensure that they are used efficiently 
and no single relay or set of relays become overloaded. Fig¬ 
ure [6] shows a snapshot of the distribution of relay capacities 
available during the period of this study, for all relays in the 
Tor system and for relays selected using the linear program 
described previously. 

We observe that since our relay selection method does 
not take relay bandwidth distributions into account, it of¬ 
ten selects lower capacity relays as exits, during circuit cre¬ 
ation (Figure [8b| . This skew towards lower capacity relays 
is rectified by augmenting the relay selection algorithm with 
information about relay capacities during circuit construc¬ 
tion. This is done by introducing a user tunable param¬ 
eter a G [0, 1]. This tuning parameter allows circuits to 
select relays with a probability equal to some combination 
of advertised relay bandwidth (obtained via Tor consensus 
data available within the client for each relay) and the lin¬ 
ear program outputted probability. As a increases, relays 
are selected more in line with their bandwidth capacity dis¬ 
tribution than the linear program generated distribution. 

This is done by generating a weighted combination of the 
two distributions. First, the linear program generates a dis¬ 
tribution for relay selection (Di p ). Next, a bandwidth based 
relay selection distribution ( Db w ) is generated. For this, in¬ 
formation from the Tor consensu^f] data is used to obtain 
advertised relay capacities. Then, for each possible entry- 
and exit-relay combination (i, j), a probability of selection is 
done by the normalization of (.15 x BW(i)) + (.85 x BW(j)) 

3 Informat ion regarding relay performance that is generated 
by Tor directory authorities and received by clients once 
each hour. 


































values. Here BW(i) denotes the advertised bandwidth of 
the I th relay. Weights of .15 and .85 were chosen in order 
to increase the exit-relay throughput (experiments revealed 
that exit-relays were often the bottleneck of the circuit - 
perhaps because of their relatively small number). Given 
these distributions, the a distribution (D a ) is computed as 
follows: 

D a (i,j) = norm(a x D bw (i, j) + (1 - a) x D ip (iJ )) 

Therefore, security conscious users may select a = 0 to en¬ 
sure that all circuits are constructed with the goal of mini¬ 
mizing risk from each attacker, while users willing to trade¬ 
off some security for performance may increase a to create a 
proportional number of circuits using faster and potentially 
more dangerous relays. In Section [5] we show how changes 
to a affect Astoria’s security and performance. 

4.4 Implementing Astoria 

In order to make the current Tor client AS-aware and to 
integrate our measurement toolkit (Section |3}, the following 
modifications were made. 

AS-aware on demand circuits. First, the Tor client 
was modified to perform offline IP to ASN mapping using a 
database downloaded from APNIC [33] for every incoming 
request. Note that since the entire database (9 MB) is down¬ 
loaded, the client does not reveal its intended destination to 
any lookup services. 

Next, modifications were made to the way requests were 
allocated to circuits. The vanilla Tor client performs pre¬ 
emptive circuit construction in order to serve requests as 
they arrive (increasing performance significantly). This is 
unfortunately generally infeasible for a destination- and AS- 
aware client. Although one may consider pre-constructing 
AS-aware circuits for a set of frequently served requests 
ASes, the performance benefit is marginal, at best. This 
is caused by third party requests for less popular AS des¬ 
tinations embedded in popular Web pages. Astoria, there¬ 
fore, only performs on demand circuit construction. For 
each incoming request, Astoria first checks if there are ex¬ 
isting circuits serving the same destination AS. The request 
is attached to the most suitable such circuit if it exists. 

Circuit construction and toolkit integration. As¬ 
toria creates a new circuit if and only if a request arrives 
requiring a circuit to connect to an IP address whose AS 
has no existing or usable circuits. In such cases, the client 
and destination ASNs were passed to the circuit construc¬ 
tion and relay selection algorithms. Circuit construction is 
performed as follows: 

• First, a list of entry- and exit-relays meeting the require¬ 
ments set by the request were obtained. If the Tor client 
is configured to utilize only guards as entry-relays, the 
list of guards is obtained. Next, if Astoria is configured 
with a > 0, information from the most recent Tor con¬ 
sensus is obtained to generate the distribution D bw for 
each entry- and exit-relay combination. 

• The Astoria client performs lookups to the offline IP- 
ASN database to perform mapping between entry- and 
exit-relay IP address and AS numbers. These, along 
with the client and destination AS numbers are then 
passed to our AS-path prediction and attacker measure¬ 
ment toolkit (Section [3| via a socket connection. 

• The toolkit returns the list of ASes on each forward- 


and reverse-path between the client and every poten¬ 
tial entry-relay and the destination and every potential 
exit-relay. In order to improve performance, paths were 
cached for frequently queried destinations. Precomputa¬ 
tion or caching of paths between the client and the high- 
uptime entry-relays and destinations and high-uptime 
exit-relays also help improve performance. 

• The returned paths are checked for the presence of com¬ 
mon ASes in the entry and exit AS path sets. If there are 
paths without an attacker, the linear program need not 
be invoked. Instead, one of the attacker free entry- and 
exit-relay combinations is chosen at random since this 
is a valid output for the linear program in such cases. 
Alternately, Astoria may also choose a safe entry- and 
exit-relay combination according to the generated D bw 
probability distribution. We see the impact of this mod¬ 
ification in Section [5] 

• If there are no attacker-free relay combinations, the lin¬ 
ear program is invoked in order to generate the distri¬ 
bution (Dip) that minimizes the probability of the most 
likely attacker. 

• D a is generated by normalizing and weighting the D bw 
and Di p distributions. Finally, an entry- and exit-relay 
combination are selected in accordance to this distribu¬ 
tion. The remainder of the circuit construction process 
remained unchanged from Tor. 

Although the above implementation appears computa¬ 
tionally intensive, we will show in Section [5] that the perfor¬ 
mance loss over vanilla Tor is reasonable, and the security 
benefits are high. 

5. ASTORIA EVALUATION 

We evaluate Astoria along multiple axes. First, we con¬ 
sider the performance of Astoria by measuring the time re¬ 
quired to load webpages and its ability to be a good Tor 
citizen by selecting bandwidth-rich relays. Second, we eval¬ 
uate the security enhancements provided by Astoria. We 
show that Astoria constructed circuits are a good defense 
against the adversary model described in Section [2] 

5.1 Evaluation methodology 

For our evaluation of Astoria, we performed page loads of 
the Alexa local Top 100 websites in the following 10 coun¬ 
tries: Brazil (BR), China (CN), Germany (DE), Spain (ES), 
France (FR), England (GB), Iran (IR), Italy (IT), Russia 
(RU), and the United States (US). As before, a VPN ser¬ 
vice was used to connect to servers in each of the above 
countries. 

The Astoria client was tested under various configura¬ 
tions. First, the value of a was set at 0 (using only the 
security-oriented LP for selection), .5 (hybrid relay selec¬ 
tion) , and 1 (relay selection based only on relay bandwidth). 
Second, in the case where there exists a safe relay selection 
option (i.e. } we can build a circuit with no attacker), we 
consider selecting a safe relay pair uniformly at random and 
selecting a relay pair based on the distribution of the adver¬ 
tised bandwidth of the routers. 

For each configuration, the Astoria client maintained logs 
to record the entry- and exit-relays available for each cir¬ 
cuit being constructed, the bandwidth advertised by each 
of these relays, the number of relay-selection combinations 
with and without attackers, and the actual circuit utilized to 



Figure 7: CDF of page load times for vanilla Tor and Astoria 
with a = 0, .5, and 1 (cumulative for Alexa local Top 100 of 10 
countries). 


serve each incoming request. Network traces were recorded 
to allow analysis of page load times and round-trip times. 
Additionally, to understand the performance of our mea¬ 
surement toolkit, logs were maintained to keep track of the 
time spent on AS-path calculation described in Section [3] 

In all configurations, the default setting of 3 entry guards 
was used. To compare performance with Tor, the same page 
loads were performed using the default Tor client. 

5.2 Performance Evaluation 

Page load times. Figure [7] shows the distribution of page 
load times when using vanilla Tor and Astoria under several 
configurations of a. Interestingly, the median performance 
penalty of using the most secure configuration (a = 0) of 
Astoria is approximately eight seconds, while the median 
penalty to less secure configurations (a =.5 and 1) are two 
and six seconds, respectively. This property stems from the 
fact that Astoria cannot perform proactive circuit construc¬ 
tion and must wait for the request to come in before creating 
a circuit. The majority of the performance impact of Asto¬ 
ria stems from this lack of circuit preconstruction and not 
the selection of more secure relays. 

Load balancing. Figure [8] shows the bandwidth capacity 
distributions of the relays selected by the Astoria client for 
varying levels of a. When Astoria prioritizes relay band¬ 
width above security (a = 1) the 75th percentile of exit- 
relay bandwidth is much higher than the security-oriented 
prioritization, with a difference of 7 MB/s. 

Interestingly, one might conclude from Figures [7] and [8] 
that the actual performance bottleneck arises from Astoria’s 
inability to pre-emptively construct circuits. 

Overhead of path prediction. Figure [9] shows the CDF 
of the total amount of time spent on computing AS paths, 
for each site. We see that for about 50% of all sites (Top 100 
sites of 10 countries), the time spent on path computation 
is negligible. This is due to the high frequency of repeated 
occurrences of destination ASes in the Top 100 sites - re¬ 
sulting in the AS path for each exit-relay to that destination 
being in the toolkit’s cache. In 60% of the cases where re¬ 
sponses were not cached (and ~ 80% of the cases, overall), 
computing AS paths required under 3.8 seconds. 

Alternate strategies for selection of safe paths. As 

we observed in Section [3] in a majority of cases there are sev¬ 
eral attacker free entry- and exit-relay selections that may 
be used for circuit construction. While Astoria, by default, 
selects between these safe pairs uniformly at random, in or- 



(a) Entry relay distribution. 
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(b) Exit relay distribution. 

Astoria a = 0 — Astoria a = 1 — 

Astoria a = .5 — Available tor relays 

Figure 8: Distribution of Astoria selected entry- and exit- relay 
bandwidths, compared to available relay bandwidths. 



Figure 9: CDF of time spent on AS path computation per site. 


der to improve performance and load balancing efforts even 
further, one may select from them according to their avail¬ 
able bandwidth capacity. Such an optimization increases 
throughput and reduces page load time without impacting 
security. The performance benefit of this optimization is 
illustrated in Figure |10| Specifically, this optimization re¬ 
duces the median page-load time penalty by a sizable 1.6 
seconds when a = 0. 

5.3 Security Evaluation 

Table [4] shows the percentage of circuits under the threat 
of attack for various configurations of Astoria and compares 
them with the Tor client. We see that in it’s most secure con¬ 
figuration, Astoria achieves its goal of completely avoiding 
selection of attacker occupied paths, when there are alter¬ 
natives. For 5.1% of all source and destination pairs that 
were evaluated, Astoria was unable to find a safe entry- and 
exit-relay pair and resorted to relay selection based on the 
linear program described in Section [4] Therefore, even in 
these cases, there were no attackers that were able to per- 
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(a) Entry relay distribution. 

> 



(b) Exit relay distribution. 
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(c) Distribution of page load times (sec). 

Standrd Astoria a = 0 — 

Optimized Astoria a = 0 — 

Available tor relays 

Figure 10: Performance benefits of load balancing across safe 
circuits. 


form de-anonymization on a large number of client generated 
circuits. 

Effect of the tuning parameter (a) on security. We 

find that the paths to and from high capacity relays are often 
occupied by common (or, sibling) ASes. Therefore, as the 
Astoria client attempts to skew towards higher capacity re¬ 
lays, the fraction of attacked circuits increases quite rapidly. 
At a = .5, the security provided by Astoria is comparable 
with that provided by the Tor client. 

6. DISCUSSION 

We now discuss how Astoria could be augmented and im¬ 
proved with more recent and ongoing developments from the 
network measurement community. We also discuss potential 
performance enhancements for Astoria. 

Protecting against other classes of attack. We note 
that Astoria focuses on adversaries who may lie on asym¬ 
metric network paths between the client and entry; and exit 
and destination, respectively. However, Sun et al. 18] 
highlight attacks based, not only on static path properties, 
but also dynamics of BGP (e.g., hijacks, routing instability). 
Taking this sort of attack into account is challenging as it 



Vanilla Tor 

Astoria 
(a = 0) 

Astoria 
(a = .5) 

Astoria 
(“ = 1) 

Main 

42.4% 

1.5% 

27.2% 

43.8% 

All 

58.6% 

5.1% 

54.8% 

71.2% 


Table 4: Percentage of circuits carrying main requests for the 
Alexa Top 100 websites (of 10 countries) that are under threat 
and percentage of all circuits under threat for various config¬ 
urations of Astoria and Vanilla Tor. 


requires realtime access to interdomain routing data and in¬ 
telligent analysis to identify incidents that may impact the 
safety of the client’s path. In the future, we may integrate 
subscriptions to BGP hijack data sources (e.g., Argus [34] , 
or more rece nt efforts at building a real-time interception 
detector [35]) into Astoria to allow it to operate on dynamic 
BGP paths. 

Improving path prediction. Astoria relies on paths 
predicted via simulations of the BGP decision process on 
empirically derived maps of the AS-level topology. How¬ 
ever, while these paths will capture the actual measured 
path 65-85% of the time [22], they do not precisely indicate 
the path that will be taken. We note that novel path mea¬ 
surement tools are on the horizon (e.g., Sibyl [36]) that take 
into account richer vantage point sets than prior work (e.g., 
PlanetLab used by iPlane [26] vs. RIPE Atlas [37] used by 
Sibyl). An interesting future direction is determining how 
such measurement planes can be integrated into a Tor client 
(e.g., to operate in an offline mode or via a secured querying 
interface). 

Performance enhancements. While the performance of 
Astoria in its most secure configuration is reasonable for the 
benefits provided, and in line with expectations of Tor users, 
we note that there are two primary avenues for improvement 
- in addition to the alternate relay selection approach dis¬ 
cussed and evaluated in Section [5] 

• Currently, our assembled measurement toolkit is not 
completely integrated and built with Astoria, and com¬ 
munication is performed using socket reads and writes. 
We expect sizable performance benefits from a complete 
native integration of the toolkit. 

• From our performance evaluation it is clear that even in¬ 
spite of selecting faster relays, Astoria is unable to match 
the performance of Tor. This difference in performance 
is attributed almost completely to our inability to pre¬ 
emptively construct circuits. One direction for future re¬ 
search is smart caching and pre-constructing of circuits 
for Astoria. 

Usability of Astoria. From our evaluation of Astoria, 
it is clear that the performance-security trade-off is favor¬ 
able only in its higher security configurations. At high se¬ 
curity configurations, Astoria is able to perform good load 
balancing, achieve reasonable throughput, avoid asymmet¬ 
ric colluding attackers whenever possible, and even handle 
situations where safe circuits are not possible. 

However, at lower security configurations, the perfor¬ 
mance offered by Tor is clearly better, and its security, only 
slightly worse. Therefore, Astoria is a usable substitute for 
the vanilla Tor client only in scenarios where security is a 
high priority. 







































































7. CONCLUSIONS 

In this paper, we have leveraged current AS-level topolo¬ 
gies and models of interdomain routing to quantify the po¬ 
tential for timing attacks where an adversary can leverage 
asymmetric Internet routing and collude with others within 
the same organization. Specifically, we have shown that 58% 
of the time, while loading pages of common websites, Tor 
constructs circuits that are vulnerable to such attackers. 

To mitigate the threat of asymmetric correlation attacks 
by colluding attackers, we also developed Astoria- an AS- 
aware Tor client. In addition to providing high-levels of 
security against such attacks, Astoria also has performance 
that is within a reasonable distance from the current Tor 
client. Unlike other AS-aware Tor clients, Astoria also con¬ 
siders how circuits should be built in the worst case - i.e., 
when there are no safe relays that are available. Further, 
Astoria is a good network citizen and works to ensure that 
the all circuits created by it are load-balanced across the 
volunteer driven Tor network. 

Our work highlights the importance of applying current 
models and data from network measurement to inform relay- 
selection and help avoid timing attacks. Astoria also opens 
multiple avenues for future work such as integrating real¬ 
time hijack and i nter ception detection systems (to fully 
counter RAPTOR [l8j attacks) and understanding how new 
measurement services can be leveraged by a Tor client with¬ 
out defeating anonymity. 
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